Data processing systems generally include a plurality of modules which execute on a central processing unit (CPU). An operating system may be used to interface the modules to the CPU. Each module may be a separate computer program such as a word processing or spreadsheet program, or may be a subroutine or a group of subroutines that act as a unit. It will be understood that modules may also include hardware as well as software components, such as a sound card module. An operating system may also be considered as one or more modules. Each of these modules executes in the data processing system, serially or concurrently.
In data processing system design, it has long been recognized that well-defined modules can provide a data processing system that is easy to maintain and update. Accordingly, modular programming techniques and object oriented programming techniques have been used to design well-defined modules.
In a well-defined module, the module exposes an interface that exchanges data and otherwise interacts with other modules, with an operating system and/or with the central processing unit. However, the details behind the interface, and the data and algorithms that are used to implement it, are maintained hidden within the module. Accordingly, external interaction of the module takes place only through a well-defined interface. Thus, the module is easy to maintain or upgrade by preserving the well-defined interface when changing the internal workings of the modules.
Many modules use configuration data to govern their operation. For example, a word processing program may include configuration data regarding foreground and background colors, fonts, default document formats and other configuration information. As another example, an operating system may include configuration files for control panels, printers and task bars. Accordingly, modules generally include a configuration file associated therewith.
Many modules will have common configuration parameters, such as colors, fonts, task bars and the like. In order to improve the ability to edit these configuration parameters globally, it may be desirable to provide a single configuration file as a persistent file of configuration information for all modules. This configuration file may be human-readable or may only be machine-readable. In either case, a single file for multiple modules is generally desirable to reduce clutter and improve reliability of the data processing system.
Unfortunately, the use of a single configuration file may be contrary to the provision of well-defined modules. In particular, if there is a single configuration file, and a single module that reads that configuration file, then each other module may need to expose, as part of its external interface, all of its configurable parameters. However, this may expose information which otherwise may not need to be exposed to other modules, and thus may violate the basic concepts of modular programming.
Moreover, if a module changes a configuration parameter, the configuration file reading module may also need to change. Again, this may violate the principles of modular programming.